This invention relates to the field of event processing. In particular, the invention relates to prioritizing event processing based on system workload.
In a complex event processing system, there can be a wide variety of events and rules to act upon those events deployed in a central processing system. These types of system can also experience heavy loads of tens of thousands of events per second. The number of events being sent to the system may also vary significantly over time, where at certain periods of the day there could be thousands of events per second arriving, whereas at other times there could be several hours where no events are received. In order to handle such workloads there are two traditional approaches.
The first approach is to size the system so that it is able to process at the expected peak rate. This can add considerable expense to the solution, as software is typically charged per number of processors. For example, if 12 cores are required to handle a peak load that lasts for one hour per day, and only one core is needed to handle the load for the other 3 hours, the client would be paying for all 12 cores.
The second approach is to size for a lower rate, and allow messages to build up on input queue. If the system does not have sufficient processing power to handle the input rate, then events will typically build up on the input queue assuming an asynchronous messaging event processing system.
Events building up on the input queue can have several drawbacks:
1) If a large number of messages build up on the input queue then it can slow down the processing of events that may be time sensitive, for example, certain types of event may need to be processed within seconds of arriving. Message priorities could be used to mitigate this problem, which should allow higher priority events to be processed first, but this relies on the message producer to set the priority, whereas it would typically be the business user that is defining the event processing logic that would understand which events are higher priority, and as new logic is added priorities could change, which would be difficult to distribute to all message producers.
2) Handling a large number of messages on a queue can add significant load to the messaging system, particularly if messages have different priorities, so this could slow the system down even more when it is under load.
Therefore, there is a need in the art to address the aforementioned problems.